Workflow Process Definition Language – Development and Directions of a Meta-Language for Workflow Processes
نویسندگان
چکیده
Meta-Languages for the definition of processes serve several purposes. They can be employed as an integration platform for the exchange of process models that are specified in proprietary languages, their expressiveness can serve as a benchmark for the selection of a application specific modeling language and they can be used for the application-independent specification of process models that can then be transformed into the language relevant for the domain-specific context. In this paper we outline several approaches of meta-languages for process specification and compare them to the Workflow Process Definition Language as defined by the Workflow Management Coalition. 1 Meta-Languages for Workflow and Process Modeling 1.1 Workflow Management Technology The support of process enactment through workflow management systems has increased significantly in both administrative and technical domains. The development of workflow technology can be traced back to various origins, such as office information systems [1], computer supported cooperative work (CSCW) [2], imaging and document management [3] as well as advanced database technologies [4, 5] (for a discussion of the origins of workflow cf. e. g. [6]). Workflow management systems support the enactment of processes by coordinating the temporal and logical order of the elementary process activities (sometimes called elementary workflows and described as the behavioral and functional/control-flow aspect of a workflow) and supplying the data, resources and application systems necessary for the execution of the functions (these are the informational, organizational and operational/technological aspects of a workflow, for a discussion of the different aspects cf. [7]). Most workflow management systems distinguish between a buildtime component, used for the specification of workflow models, and a runtime component that is used during the invocation of workflow instances. The buildtime models are either interpreted by the runtime engine or compiled into a pseudo-code that can be executed by the runtime component. In the recent past several research projects focused on the weakening of this separation, thus enabling the modification of running process instances or the ad-hoc planning of process parts that are unknown at buildtime (cf. e. g. [8, 9]). 1.2 Languages for Workflow Process Specification For the specification of workflow processes, several languages have evolved over time. Almost any vendor relies on a proprietary format for the specification of workflow models, only few use existing process modeling languages such as high-level Petri-Nets for the modeling component of their product (cf. e. g. the discontinued LEU system, that used FUNSOFT-nets for the specification of workflow processes [10]). According to CARLSEN, the existing languages for workflow process modeling can be classified in five distinct groups [9]: § IPO (Input-Process-Output)-based languages, such as the activity networks used in IBM MQSeries Workflow [11]. These languages describe a workflow as a directed graph of activities, denoting the sequence of their execution. § Speech-Act-based approaches (sometimes called Language Action approaches) as used in Action Technologies Action Workflow product [12]. These approaches model a workflow as an interaction between (at least) two participants that follow a structured cycle of conversation. Namely the phases negotiation, acceptance, performance and review are distinguished. § Constraint-based modeling methods, such as Generalized Process Structure Grammar (GPSG), proposed by GLANCE et al. [13]. These approaches describe a process as a set of constraints, leaving room for flexibility that is otherwise governed by the restrictions of the IPOor Speech-Act-based approaches. Constraint-based modeling languages are typically text-based and resemble traditional programming languages, whereas a graphical representation of these models seems difficult. § Role-modeling based process descriptions, such as Role Activity Diagrams (RADs). § Systems thinking and system dynamics, that are used in conjunction with the concept of learning organizations (cf. e. g. [14]). In the following sections we will focus on the first three classes of modeling languages, namely IPObased, Speech-Act-based and Constraint-based languages. 1.3 Meta-Languages for Process Specification The diversity of approaches and tools as described in the previous sections leads to severe problems for users, that wish to employ several products that follow different modeling paradigms, as well as for users that plan to integrate their business processes with previous and latter stages of the value chain, i. e. suppliers and customers. In order to facilitate the integration of different tools from different vendors, several initiatives have emerged that focus on the development of meta-languages for process modeling. A meta language is a superset of constructs that can be found in process modeling languages and that can be used to map concepts from one process modeling language through a construct of the meta language to a related concept of another modeling language. 1.4 Related Work In the field of database management systems the concept of schema integration has been extensively discussed in the literature (cf. e. g. [15]), however, in the field of process management the close relationship between the syntax and the semantics of a process model create new problems. KNUTILLA et al. present a comprehensive evaluation of process modeling languages [16]. In the course of the NIST PSL project (see section 2.3) twenty-six process specification languages were evaluated with regard to their applicability to the manufacturing domain, which serves as the origin for the PSL requirements. The evaluation of the modeling methods of workflow management systems can be found in two approaches. HEINRICH et al. focus on the practical effects of workflow technology in a laboratory study, comparing process enactment with and without workflow support [17]. LEI and SINGH [18] as well as ZUR MÜHLEN [19] focus on the evaluation of workflow management systems using their meta models. However, the grammar of the underlying modeling methods is not analyzed in detail. 2 Five Meta-Languages for Process Modeling In the following sections we present five distinct approaches of meta languages for process modeling: Workflow Process Definition Language, Process Interchange Format, Process Specification Language, Generalized Process Structure Grammar and the Unified Modeling Language. For each of these languages their origin and current status are described. 2.1 Workflow Process Definition Language (WPDL) The Workflow Process Definition Language (WPDL) was first introduced by Workflow Management Coalition (WfMC) in 1994. The WfMC is a non-profit, international organization committed to the development of standards in the fields of workflow technology. The main work of the WfMC focuses on the standardization of terms used in the context of workflow management applications [20] and the interoperability of different systems [IOP]. Currently the WfMC consists of over 200 members, namely vendors, users, research institutions and analysts dealing with workflow technology. The WfMC consists of two main groups: The technical committee (TC), which is organized in working groups that address various areas of workflow technology and develop standard documents, and the external relations committee (ERC), which is responsible for the publication of the TC standards and consists of a number of country contacts for parties interested in the work of the WfMC. Both groups are controlled by a steering committee that supervises the consistency of the work and sets the general direction for the work of the WfMC. Although a standardization body in its own right, the WfMC works closely together with other standardization organizations, such as the Object Management Group, whose workflow management facility [21] was submitted by a consortium of WfMC member companies. The specification of the WfMC form around a reference model (cf. fig. 1) that describes the basic elements of a workflow management system with a focus on the interfaces to external systems. This reference model should not be confused with the internal representation of a workflow management system as described e. g. by JABLONSKI and BUSSLER [7], since the model in figure 1 only describes those parts of the workflow management system that are potential candidates for interoperability with other software systems. Figure 1. Workflow Management Coalition Reference Model The five interfaces of the reference model are linked to the workflow enactment services via a Workflow Application Programming Interface (WAPI), that has been defined on an abstract level [22]. The relevant interface for the exchange of process model data is Interface 1 [23]. The Workflow Process Definition Language (WPDL) was established as a meta-language for the exchange of buildtime workflow process models through a batch procedure (import/export of process models). The keywords of WPDL are based on the terms defined in the WfMC glossary. The language design is based on a minimum meta-model that defines the elementary components that have to be supported by a tool that reads and/or writes WPDL. This minimum meta-model can be extended by vendor-specific extensions. The meta-model of the process part of WPDL is depicted in figure 2 (for reasons of simplicity the cardinalities of the relationship types have been left out of the diagram). The organizational/resource model of WPDL is a specialization of the Workflow Participant Specification Entity Type and thus not displayed in the figure. Core concept of the WPDL is a Workflow Process Definition that is composed of one or many Workflow Process Activities. The ordering of activities is determined by Transition Information elements that connect single activities. For more complex routings a Transition may rely on Workflow Relevant Data, that is, data from application systems which is relevant for the sequence of activities (i. e. the amount of a credit request that determines, whether the VP of the bank has to sign the approval or not). The entity types of WPDL are not extendable, however, user-defined attributes may be added to the single entity types. Moreover, references to external data sources as connecting points are explicitly denoted, such as the referral to an external organizational repository, to system and environmental data or to invoked application systems. In order to establish conformance for workflow management systems that follow different modeling paradigms, several conformance classes have been defined. These conformance classes limit the number of elements a workflow management system has to support in order to claim conformance to WPDL. These restrictions include e. g. a block-restriction for workflow systems, that require each split in the process to be followed by a similar join in a later part of the process. Currently a mapping between WPDL and XML is under discussion in order to enable the exchange of process models through an internationally defined standard encoding language. A standard for this mapping is expected to be released within the year 2000. Figure 2. Meta model of the WPDL process modeling elements. 2.2 Process Interchange Framework (PIF) The Process Interchange Framework was developed as a standardized language for the processes recorded in the MIT Process Handbook project [24]. The Process Handbook project is targeted at the collection of representative business processes from different organizations and the presentation of these processes in order to facilitate the comparison and selection of alternative processes in actual Workflow Process Definition Workflow Participant Specification Workflow Relevant Data Workflow Process Activity Organisational Model Workflow Application Declaration (Sub)Process Definition
منابع مشابه
Process Query Language: A Way to Make Workflow Processes More Flexible
Many requirements for a business process depend on the entire workflow environment that includes common data for all the population of processes, state of resources, state of processes, etc. The natural way to specify and implement such requirements is to put them into the process definition. In order to do it, we need: (1) a generalised workflow meta-model that includes data on the workflow en...
متن کاملAutomatic Workflow Generation and Modification by Enterprise Ontologies and Documents
This article presents a novel method and development paradigm that proposes a general template for an enterprise information structure and allows for the automatic generation and modification of enterprise workflows. This dynamically integrated workflow development approach utilises a conceptual ontology of domain processes and tasks, enterprise charts, and enterprise entities. It also suggests...
متن کاملAutomatic Workflow Generation and Modification by Enterprise Ontologies and Documents
This article presents a novel method and development paradigm that proposes a general template for an enterprise information structure and allows for the automatic generation and modification of enterprise workflows. This dynamically integrated workflow development approach utilises a conceptual ontology of domain processes and tasks, enterprise charts, and enterprise entities. It also suggests...
متن کاملA Framework for Business Process Simulation Based on Multi-Agent Cooperation
Most enterprise information systems can be viewed as discrete event systems (DES). Workflow is the computerized business processes. Workflow technology is one of key techniques in current enterprise information system. As the analyzing tool for workflow model, process simulation can support business process reengineering (BPR) effectively. Defects and bottlenecks of enterprise processes can be ...
متن کاملBusiness Process Query Language a Way to Make Workflow Processes More Flexible
Many requirements for a business process depend on the workflow execution data which include common data for all the population of processes, state of resources, state of processes, etc. The natural way to specify and implement such requirements is to put them into the process definition. In order to do it, we need: (1) a generalised workflow metamodel that includes data on the workflow environ...
متن کامل